IBIS Macromodel Task Group Meeting date: 27 August 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark Wei-hsing Huang Aurora System: * Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Samsung: Jun-Bae Kim Siemens EDA (Mentor): * Arpad Muranyi Randy Wolff Signal Edge Solutions Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the meeting scheduled for August 20th had been cancelled. - Arpad asked whether we should cancel the meeting scheduled for September 3rd, the day after the US Labor Day Holiday. The group decided to cancel. - Michael noted that the Editorial Task Group will reconvene on Friday, September 6th, to begin work on IBIS 8.0. He suggested Arpad's recent email regarding some inconsistencies in language in the specification could be discussed there. He welcomed anyone interested in drafting IBIS 8.0 to join the Editorial Task Group meetings. ------------- Review of ARs: Kinger: Send his "Add Support of Power Delivery (PD) Analysis in IBIS" to the ATM list. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 13th meeting. Michael moved to approve the minutes. Walter seconded the motion. There were no objections. -------------- New Discussion: BIRD220.1 update: Arpad reported that Yifan had begun testing with the SPICE circuit he had shared with her (see minutes from July 30, 2024), but she had not completed the case study and was not yet ready to report on the results. [Ramp] and Ts4file: Michael briefly reviewed the Ts4file section (10.10) of the specification. He said the issue is that the ibischk parser does not modify its behavior at all when Ts4file is used. The parser continues to attempt to the check the [Ramp] keyword value vs. what would be expected from the I-V and V-t tables. He said he had originally proposed adding language to specify the way in which the legacy analog keyword data is measured when Ts4file is used, but at previous ATM meetings it had been pointed out that Ts4file was supposed to replace the legacy analog data entirely. Michael noted that the [Ramp] keyword is required in all [Model]s, and he noted that he had recently sent out proposed language for a parser BUG report to address the current behavior. The proposed BUG language states: The intent of the Ts4file parameter in IBIS-AMI models is to replace all analog information for the buffer, including the [Ramp] keyword, I-V table data (i.e., [Pulldown], [Pullup], etc.) and V-t data (i.e., [Rising Waveform] and [Falling Waveform]). As a result, the IBISCHK parser should not check for consistency between I-V and V-t and/or [Ramp] data when Ts4file is present. The BUG suggests that the parser should instead issue a message of the form: "Ts4file detected; analog keywords including [Ramp], [Rising Waveform], [Falling Waveform], and any I-V tables are ignored" Walter said that if you have an AMI [Model], and it uses Ts4file, then it should not provide any legacy I-V and V-t table data. [Ramp] is still required, but Walter agreed that if I-V and V-t data are not provided then there's no checking for their consistency with [Ramp]. However, if the [Model] uses Ts4file and it also provides I-V and V-t tables, shouldn't a simulator be able to use the I-V and V-t data in non-AMI simulations? If the model maker provided a Ts4file for AMI purposes, but they also performed a SPICE->IBIS and provided the legacy analog data, why not have the parser perform the I-V and V-t vs. [Ramp] tests? Michael agreed and said that this had been his original point of view. Michael noted, however, that many tools use [Ramp] as fundamental indication of bandwidth limits. So, we have to make sure [Ramp] is consistent with what's in in the Ts4file. Walter asked why you can't just run a simulation with the Ts4file driver circuit (10.10.1) into a 50 Ohm load? He said that would give you the information you need for the [Ramp] values. Arpad and Michael said the parser isn't capable of running that "simulation" to confirm the [Ramp] information. Arpad said that ideally [Ramp] should be checked against legacy analog I-V and V-t data, Ts4file, and even [External Model] if they are provided. Fangyi said this would be nice, but the work might be beyond the scope of the parser. He said we should at least add language to the specification making it clear to model makers that the dV/dt value(s) in [Ramp] should be consistent with the Ts4file. Walter said that a Ts4file into a 50 Ohm load has a very simple solution, and the parser wouldn't need to run a full "simulation." Fangyi said Ts4file language clarifications weren't necessary, since the specification already says it is for AMI purposes. Ts4file is for AMI, and the legacy analog data might be used for SPICE/transient simulations if it's provided. Arpad said it isn't quite that clear cut. He said that saying Ts4file is "specifically designed for AMI applications" is vague. He said an AMI simulation starts with the channel characterization portion. The question is, how do you do it? Before we had Ts4file, the simulator ran a step response simulation and took the derivative to get the impulse response (IR). Now, if Ts4file is provided, you can compute the IR the old way, or you could possibly go directly from Ts4file straight to an IR. There are two options now. Fangyi agreed and said that the language should be more clear on that point. Arpad said that Ts4file was invented for AMI purposes, but why would we prevent Ts4file from being used for normal time domain simulations? Fangyi said that is what the specification currently says, "...By definition, the placement of the Ts4file information within .ami files makes the Ts4file data exclusively limited to AMI applications." Fangyi said we should decide whether we want Ts4file to be used in SPICE type transient simulations, or only for AMI channel characterization. Michael said he thought that we should only use Ts4file for the channel characterization portion of an AMI simulation, and it should not be used generally for non-AMI simulations. He said that fact that Ts4file is an AMI parameter strongly suggests it's only for AMI. Arpad said we should create language that makes that suggestion, but he was not sure we want to prohibit the use of Ts4file outside of AMI. Fangyi said a model developer might intend that the Ts4file only be used for AMI channel characterization, but a model user may not know that unless the specification says something about it. He said that if we want to limit Ts4file to AMI channel characterization, then we may want to require the legacy analog keywords to be provided. Arpad said in that case we would want to check to make sure the analog keyword data is consistent with the Ts4file data. Michael and Fangyi proposed changing the language to state that Ts4file is for "analog simulation for channel characterization." Arpad said this language could cause confusion, as we keep referring to the "analog portions" of the [Model] when we discuss I-V and V-t data, etc. Michael suggested "initial channel characterization" instead. Fangyi and Arpad suggested that, regardless of what we decide to ask the parser to check, we should add language making it clear to model makers that the [Ramp] data should be consistent with Ts4file data and/or legacy I-V and V-t data if they are provided. Fangyi asked whether [Ramp] and [C_comp] are always required. Fangyi and Arpad noted that we have the same issues with [Ramp] consistency when [External Model] is used that we do when Ts4file is used. The group reviewed IBIS 7.2 for language related to whether [Ramp] and [C_comp] are required. Section 6.3.6, External Model, specifically states that [Ramp] must still be provided. However, C_comp is listed amongst the subparameters that may be omitted in a [Model] specifying [External Model]. Arpad noted that on page 61, C_comp (or C_comp_xxx subparameter(s)) are listed as required, but no mention is made of the fact that they aren't required in the [External Model] case. Michael said we could add the [External Model] disclaimer to page 61. Arpad asked why, in Section 6.3.6, page 137, the V-t waveform keywords aren't listed amongst the keywords that can be omitted. Michael said they're never required. Arpad agreed, but he said neither are the I-V table keywords, and they are listed as keywords that can be omitted. Michael agreed that we might want to add the [Rising Waveform], etc., V-t keywords to page 137. Michael noted that page 136 contains the statement about the intended use of [Ramp] data: However, when used within the scope of [External Model], the [Ramp] keyword is intended strictly to provide EDA tools with a quick first-order estimate of driver switching characteristics. Arpad suggested that we should add Ts4file in addition to [External Model]. Fangyi agreed with this addition, but he wondered why we need the "when used within the scope of ..." at all. Why do we limit the scope of this statement? Removing the scope qualification statement would be the minimal change that addresses the issue. Michael said we still have to consider how we want the parser to handle these issues. He suggested that at a minimum the parser should say that if Ts4file is present then it is dominant. He asked whether we should consider having the parser perform the "mini simulation" to check [Ramp] vs. Ts4file. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: - None. ------------- Next meeting: 10 September 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives